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(54) Electronic billing with flexible biller controlled electronic bill presentment 



(57) An electronic bill presentment network includes 
a central network station and a plurality of different user 
stations. The central network station transmits bill avail- 
ability information to the user stations to identify availa- 
ble bills of different billers for the different users. 
Information associated with each available bill of a 
respective biller is available at one of multiple networks 
addresses associated with that biller. The associated 
information could, for example, be the bill itself and/or 
promotional information. Each user station is associ- 
ated with a respective one of the users and receives the 

40 

1- 



transmitted bill availability information for its associated 
user and selects one of the identified available bills, 
such as for viewing or payment. A user station associ- 
ated with a first user is linked to the first network 
address associated with the bills of the first biller, based 
on a bill selection by the first user station. A second user 
station associated with a second user is linked to the 
second network address associated with the bills of the 
first biller based on a bill selection by the second user 
station. 
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Description 

RELATED APPLICATIONS 

[0001J Th's application is related to pending Appli- s 
cation Serial No. 09/017,169, entitled "Distributed Data 
Accessing Technique', filed February 2, 1998. 

FIELD OF THE INVENTION 

10 

[0002] The present invention relates to electronic 
bill presentment and more particularly to electronic bill- 
ing with flexible, biller controlled, electronic bill present- 
ment. 

15 

BACKGROUND OF THE INVENTION 

[0003] There are two prevalent models for elec- 
tronic bill presentment that are currently used in indus- 
try. The first is an aggregation model 1 0, which is shown 20 
in Figure 1. In its simplest form, the aggregation model 
1 0 includes a customer 1 2, an aggregator 1 4, and a plu- 
rality of billers 1 6. The customer 1 2 can be, for example, 
an individual person, a family, or a business. The aggre- 
gator 14 can be a financial institution (Fl) such as, for 25 
example, a bank. Alternatively, the aggregator 14 can 
be a separate entity which acts of behalf of a sponsor 
18, which can also be an Fl such as a bank. Each biller 
16 can be of any billing institution type such as, for 
example, a local telephone company, a local electric 30 
company, a retail outlet, or a national long distance tele- 
phone company. 

[0004] Each biller 16 provides customer-related 
invoice data to the aggregator 14. The aggregator 14 
serves as an intermediary between each biller 1 6 and 35 
the customer 12 by providing bill presentment directly to 
the customer 1 2, potentially on behalf of the sponsor 1 8. 
[0005] There are two variants of the aggregation 
model 10 resulting from the ownership, or "branding", of 
the presentation experience and the communication 40 
channel between the aggregator 14 and the customer 
12. In one variant, the aggregator 14 may offer aggrega- 
tor branding, thus totally owning both the presentation 
experience and the communication channel between 
the aggregator 1 4 and the customer 1 2. In the other var- 45 
iant, the aggregator 14 may offer sponsor-branding, 
thus staying "behind the scenes" in terms of the presen- 
tation experience and supporting the communication 
channel between the aggregator 14 and the customer 
1 2 on behalf of the sponsor 1 8. so 
[0006] The second prevalent model for electronic 
bill presentment is a biller direct model 20, which is 
shown in Figure 2. In its simplest form, the biller direct 
model 20 includes a customer 12 and at least one biller 
16. In the biller direct model 20, each biller 16 retains 55 
the customer-related invoice data and the full relation- 
ship with the customer 12 (i.e., the presentation experi- 
ence and the communication channel). The customer 



12 may have software for providing a capability similar 
to Web browser bookmarking so as to allow easy navi- 
gation between billers, and thus some level of virtual 
aggregation. However, there is no actual aggregation 
such as with the aggregator 14 of the aggregation 
model 1 0 described above. 

[0007] The above-described models present a 
dichotomy between a sponsor-centric view and a biller- 
centric view of bill presentment. That is, the aggregation 
model 10 allows the aggregator 14 and/or the sponsor 
18 to use customer-related invoice data, bill present- 
ment, and the communication channel between the . 
aggregator 14 and the customer 12 for cross-selling or" 
other peripheral services. The biller direct model 20, on 
the other hand, insures that control of customer-related 
invoice data, bill presentment, and the communication 
channel between the biller 16 and the customer 12 
remains with the biller 1 6. 

[0008] Also, neither of the above-described models 
adopt a truly customer-centric view. That is, neither of 
the above-described models allow a customer 12 to 
interact directly with individual billers 16 while retaining 
the benefits of interacting with a single aggregator 14 
such as, for example, the ability to retain a single 
authentication and log-in procedure and a common bill 
presentation framework. Further, neither of the above- 
described models allow a customer 12 to retain the ben- 
efits of interacting with a single aggregator 14 while 
allowing the aggregator 14, billers 16, and sponsor 18 to 
retain certain preferences such as, for example, the 
ability to retain control of customer-related data and a 
communication channel with each customer 12. 
Accordingly, it would be desirable to provide a distrib- 
uted data accessing technique which addresses the 
above-mentioned shortcomings of the above-described 
models. 

OBJECTS OF THE INVENTION 

[0009] One object of the present invention is to pro- 
vide a distributed data accessing technique that allows 
a customer to interact directly with individual billers 
while retaining the benefits of interacting with a single 
aggregator. 

[0010] Another object of the present invention is to 
provide a distributed data accessing technique that 
allows a customer to retain the benefits of interacting 
with a single aggregator while allowing the aggregator, 
billers, and sponsor to retain control of customer-related 
data and a communication channel with each customer. 
[0011] Another object of the present invention is to 
provide a distributed data accessing technique that 
allows complete flexibility as to who is offering bill pre- 
sentment: billers only, aggregator only (possibly on 
behalf of one or more sponsors), or some combination 
of the above. 

[0012] Another object of the present invention is to 
provide a distributed data accessing technique that 
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allows the biller greater flexibility in the presenting sup- 
plemental information, such as promotional materials, 
to customers as part of the electronic bill presentment 
and/or payment process. 

[0013] The above-stated objects, as well as other 
objects, features, and advantages, of the present inven- 
tion will become readily apparent from the fotlowing 
detailed description which is to be read in conjunction 
with the appended drawings. 

SUMMARY OF THE INVENTION 

[0014] In accordance with the invention, an elec- 
tronic bill presentment network includes a central net- 
work station, preferably a network server, and multiple 
user stations, each associated with one of multiple dif- 
ferent users. The user stations could be personal com- 
puters or other network devices. The stations may be 
interconnected by virtually any type of network, 
although preferably the stations are interconnected and 
communicate via the Internet 

[0015] The central network station is configured, 
e.g. programmed, to transmit bill availability information 
via the network, typically responsive to requests from 
the user stations. A database is beneficially provided to 
store the bill availability information which will be trans- 
mitted by the central network station. The database may 
be located on a network memory at the central station 
or elsewhere on the network. Preferably, the user sta- 
tions transmit requests for the bill availability information 
and the central network station transmits the bill availa- 
bility information responsive thereto. The transmitted bill 
availability information identifies available bills of differ- 
ent billers for the different users. The bill availability 
information may identify the available bills with or with- 
out providing bill summary information, such as the 
amount of each, or all, of the identified bills for a user. 
[0016] Each available bill of a respective biller is 
available at one of multiple network addresses associ- 
ated with the applicable biller. These addresses could 
be different network addresses at one or more network 
sites controlled by the biller, or different addresses at 
different network sites controlled by different entities 
other than the biller, or different addresses at a combi- 
nation of biller controlled and other entity controlled net- 
work sites. The network addresses themselves and/or 
indicators of the applicable address are preferably also 
stored in the database. 

[001 7] The network will typically include multiple dif- 
ferent biller stations. Each biller station is typically asso- 
ciated with a respective biller, although this is not 
mandatory and a single station could represent multiple 
billers. The biller station will generally be implemented 
as a network server. Hence, the first network address 
discussed above could be a network address of the 
biller station associated with the applicable biller, while 
the second network address could be a network 
address associated with the central processing station. 



[0018] Each user station Is configured, e.g. pro- 
grammed, to transmit requests, which may take the form 
of requests for bill availability information, to receive the 
transmitted bill availability information for its associated 
5 user, and to select one or more of the identified availa- 
ble bills. Identified available bills may be selected in 
order to, for example, generate a request(s) to view or 
pay the selected bill(s). Advantageously, each user sta- 
tion displays the transmitted bill availability information, 

J0 and selects identified bills on the basis of received input 
of its associated user. Because a billets bills are stored 
at more than one network address, a user station asso- 
ciated with a first user can be linked to a first network 
address associated a biller based on the selection of a 

is bill of that biller by that user station, while another user 
station associated with a second user can be linked to a 
second network address associated with the same biller 
based on selection of another bill of that biller by the 
second user station. 

20 [0019] Preferably, the transmitted bill availability 
information identifying the bill of the biller for the first 
user includes a hyperlink to the first network address 
and the availability information identifying the bill of the 
same biller for the second user includes a hyperlink to 

25 the second network address. In such a case, by simply 
clicking on the applicable bill availability information to 
select a bill, each user station is hyperlinked to the 
appropriate network address. Whether or not hyperlinks 
are utilized, the first user station is advantageously 

30 automatically linked to the first network address respon- 
sive to selection of the first bill, for example for viewing 
or payment, and the second user station is automati- 
cally linked to the second network address responsive 
to selection of the second bill. 

35 [0020] According to an aspect of the invention, the 
information associated with the identified bill of the biller 
for the first user at the first network address is promo- 
tional information. On the other hand, the information 
associated with the identified bill of that same biller for 

40 the second user at the second network address 
excludes the promotional information. The promotional 
information could, for example, be a special offering 
which the biller is targeting to only certain of its custom- 
ers, a survey which the biller is limiting to certain cus- 

45 tomers, a software upgrade which is required by only 
certain customers, or any other type of information 
which the biller wishes to present to only a selected por- 
tion of its customers. However, the associated informa- 
tion could be the bill itself, which might be presented to 

so the first biller in a manner which provides an enriched 
bill presentation experience as compared to the bill 
presentation experience provided to the second biller 
and hence the network address to which a user is sent 
could relate primarily or even exclusively to the look and 

55 feel of the presentation. 

[0021] In accordance with another aspect of the 
invention, each of the user stations is capable of gener- 
ating a directive to view or pay a selected available 
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bill(s) based on the bill availability information. It will be 
recognized that, in the case of pay directives, this will 
normally require that bill summary information, particu- 
larly the bill amount, be presented as part of the bill 
availability information. The user station can beneficially 5 
be linked, e.g. hyperlinked, to the first network address 
based on selecting a bill of the biller. Hence, in such an 
implementation the user station is linked to the first net- 
work address whether the bill itself or payment of the bill 
is requested by the user station during presentation of to 
the bill availability information. In the case where the 
user station is linked to the first network address after a 
user inputs a pay bill command and hence after the user 
has found the bill acceptable, preferably only the promo- 
tional information, and not the full bill detail, is made 15 
available to the user station at the first network address. 
[0022] According to still another aspect of the 
invention, the database for storing bill availability infor- 
mation includes identifiers of the different users along 
with the availability information for the bills of the differ- 20 
ent billers for the different users. The availability infor- 
mation for each of the available bills is associated with 
the identifier of one of the different users. The database 
also includes network location indicators. Each location 
indicator is associated with one or more of the different 25 
users and indicates a network location, e.g. a network 
address such as a URL, at which the identified available 
bills of one biller for those associated users are availa- 
ble. The locator is preferably a flag or other type indica- 
tor which is indicative of a network location different 30 
than the network location(s) at which the identified avail- 
able bills of the biller for other of the users are available. 
However, the indicator could, if desired, be the location 
address itself. 

[0023] It will also be understood by those skilled in 35 
the art, that the invention is easily implemented using 
computer software. More particularly, software can be 
easily programmed, using routine programming skill, 
based upon the description of the invention set forth 
herein and stored on a storage medium which is reada- <*o 
ble by a computer processor of the applicable compo- 
nent, e.g. a user station, a biller station or the central 
network station, to cause the processor to operate such 
that the particular component performs in the manner 
described above. 45 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0024] In order to facilitate a fuller understanding of 
the present invention, reference is now made to the so 
appended drawings. These drawings should not be con- 
strued as limiting the present invention, but are intended 
to be exemplary only. 

Figure 1 is an aggregation model for electronic bill 55 
presentment. 

Figure 2 is a biller direct model for electronic bill 
presentment. 



Figure 3 is an infrastructure diagram of a distributed 
database entity in accordance with the present 
invention. 

Figure 4 is a schematic diagram of an electronic bill 

presentment and payment system in accordance 

with the present invention. 

Figure 5 is a schematic diagram of an electronic 

payment and customer service (EPCS) entity in 

accordance with the present invention. 

Figure 6 is a schematic diagram of the electronic bill 

presentment and payment system shown in Figure 

4, extended to include certain associated directly 

related systems. 

Figure 7 is a schematic diagram of the electronic bill 
presentment and payment system shown in Figure 
4, extended to include certain associated indirectly 
related systems. 

Figure 8 is a schematic diagram of the electronic bill 
presentment and payment system shown in Figure 
4, extended to include certain associated customer 
care entities. 

Figure 9 is a schematic diagram of the electronic bill 
presentment and payment system shown in Figure 
4, extended to include a centralized customer care 
entity. 

Figure 10 is a flowchart diagram showing initial 
sign-on data and message flows between a user 
entity and a banking entity in the electronic bill pre- 
sentment and payment system shown in Figure 4. 
Figure 1 1 is a flowchart diagram showing sign-on 
and authentication data and message flows 
between a user entity, a banking entity, and an 
EPCS entity in the electronic bill presentment and 
payment system shown in Figure 4. 
Figure 12 is a flowchart diagram showing bill avail- 
ability data and message flows between a user 
entity, a banking entity, and an EPCS entity in the 
electronic bill presentment and payment system 
shown in Figure 4. 

Figure 13A is a flowchart diagram showing billing 
entity presentment data and message flows 
between a user entity, a billing entity, and an EPCS 
entity in the electronic bill presentment and pay- 
ment system shown in Figure 4. 
Figure 13B is a flowchart diagram showing billing 
aggregator bill presentment data and message 
flows between a user entity, a billing entity, an 
EPCS entity, and an established billing aggregator 
in the electronic bill presentment and payment sys- 
tem shown in Figure 4. 

Figure 13C is a flowchart diagram showing alterna- 
tive system bill presentment data and message 
flows between a user entity, an EPCS entity, and an 
alternative bill presentment and payment system in 
the electronic bill presentment and payment system 
shown in Figure 4. 

Figure 14 is a flowchart diagram showing bill pay- 
ment data and message flows between a user 
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entity, an EPCS entity, and a billing entity in the 
electronic bill presentment and payment system 
shown in Figure 4. 

Figure 15 is a flowchart diagram showing bill remit- 
tance and debiting data and message flows s 
between an EPCS entity and a billing entity and a 
banking entity in the electronic bill presentment and 
payment system shown in Figure 4. 
Figure 1 6 shows an example of a branded interface 
having a sign-on request prompt that includes a 10 
username field and a password field. 
Figure 17 shows an example of a banking entity 
home page, including a "view bills" icon, a "view 
checking account" icon, and a 'view savings 
account" icon. T5 
Figure 18 shows a first modified banking entity 
home page having a frame presenting new bill 
availability data. 

Figure 1 9 shows a second modified banking entity 
home page having a frame presenting detailed bill 20 
data. 

Figure 20 is a flowchart diagram showing customer 
service data and message flows between a central- 
ized customer service center, and an EPCS entity, 
a billing entity, and a banking entity in the electronic 25 
bill presentment and payment system shown in Fig- 
ure 4. 

Figure 21 is a flowchart diagram showing bill avail- 
ability data and message flows between a user, 
entity, an aggregator entity such as the depicted 30 
banking entity, and an EPCS entity in the electronic . . „ 
bill presentment and payment system shown in Fig- 
ure 4, modified to allow bills to be selectively pre- 
sented by at one network site or another network 
site, in accordance with the present invention. 35 
Figure 22A depicts an EPCS database for storing 
bill availability information and flags for directing a 
user to a desired network address for bill presenta- 
tion. 

Figure 22B depicts an EPCS database for storing 40 
different addresses at which bills of a biller are pre- 
sented to different users. 

Figure 23A shows a modified banking entity home 
page having a frame presenting new bill availability 
data for a first subscriber, with certain data availa- 45 
ble at a biller network address and other data avail- 
able at an EPCS network address or some other 
network address, in accordance with the present 
invention. 

Figure 23B shows a modified banking entity home so 
page having a frame presenting new bill availability 
data for a second subscriber, with certain data 
available at a biller network address and other data 
available at an EPCS network address or some 
other network address, in accordance with the 55 
present invention. 

Figure 23C shows a modified banking entity home 
page similar to that shown in Figure 23A, except 



that the home page has a frame presenting new bill 
availability data which includes total bill amounts, 
for the first subscriber, with certain data available at 
a biller network address and other data available at 
an EPCS network address or some other network 
address, in accordance with the present invention. 
Figure 24A is a flowchart diagram showing mes- 
sage flows between a user entity, a billing entity, 
and an EPCS entity in the electronic bill present- 
ment and payment system shown in Figure 4 for the 
first subscriber requesting a bill identified in Figure 
23A which is available at the biller address, in 
accordance with the present invention. 
Figure 24B is a flowchart diagram showing mes- 
sage flows between a user entity, a billing entity, 
and an EPCS entity in the electronic bill present- 
ment and payment system shown in Figure 4 for the 
first subscriber requesting a bill identified in Figure 
23A which is available at the EPCS address, in 
accordance with the present invention. 
Figure 24C is a flowchart diagram showing mes- 
sage flows between a user entity, a billing entity, 
and an EPCS entity in the electronic bill present- 
ment and payment system shown in Figure 4 for the 
second subscriber requesting a bill identified in Fig- 
ure 23B which is available at an alternate biller 
address, in accordance with the present invention. 
Figure 24D is a flowchart diagram showing mes- 
sage flows between a user entity, a billing entity, 
and an EPCS entity in the electronic bill present- 
ment and payment system shown in Figure 4 for the 
first subscriber directing payment of a bill identified 
in Figure 23C, in accordance with the present 
invention. 

Figure 25A shows another modified banking entity 
home page having a billing entity frame presenting 
detailed bill data and special promotional informa- 
tion to the first subscriber, in accordance with the 
present invention. 

Figure 25B shows another modified banking entity 
home page having an EPCS entity frame present- 
ing detailed bill data and general promotional infor- 
mation to the first subscriber, in accordance with 
the present invention. 

Figure 25C shows another modified banking entity 
home page having a billing entity frame presenting 
only promotional information to the first subscriber, 
in accordance with the present invention. 

DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT 

[0025] Referring to Figure 3, there is shown an 
infrastructure diagram of a distributed database entity 
30 in accordance with the present invention. The distrib- 
uted database entity 30 comprises a database compo- 
nent 32 and a plurality of message interfaces 34-40 for 
facilitating communication between the database com- 
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ponent 32 and other distributed database entities and 
system components. The database component 32 typi- 
cally contains data that is controlled or "owned" by the 
controller or "owner" of the distributed database entity 
30. For example, if the distributed database entity 30 is 
owned by a financial institution (Fl) such as a bank, then 
the database component 32 could contain information 
such as checking and savings account balances. It 
should be noted, however, that the database compo- 
nent 32 can also contain data from other distributed 
database entities and system components, as will be 
described In detail betow. 

[0026] The plurality of message interfaces 34-40 
includes an internal message interface 34, an external 
message interface 36, a partner message interface 38, 
and a customer care message interface 40. The internal 
message interface 34 defines messages that are used 
to communicate and query data between the given dis- 
tributed database entity 30 and other distributed data- 
base entities, or other system components having an 
internal message interface. For example, in a bill pre- 
sentment and payment system, communication 
between a banking entity and a billing entity may be 
required. The external message interface 36 defines 
messages that are used to communicate and query 
data between the given distributed database entity 30 
and any existing system(s) that are directly related to 
the given distributed database entity 30. For example, 
an Fl such as a bank can have an existing direct deposit 
account (DDA) system. The partner message interface 
38 defines messages that are used to communicate and 
query data between the given distributed database 
entity 30 and any existing system(s) that are indirectly 
related to the given distributed database entity 30. For 
example, in a bill presentment and payment system, 
communication with an established billing aggregator 
may be necessary to satisfy customer demands. The 
customer care message interface 40 defines messages 
that are used to communicate and query data between 
the given distributed database entity 30 and a customer 
care entity. For example, in a bill presentment and pay- 
ment system, a billing entity may allow a third party to 
access bill data in order to provide feedback to bill cus- 
tomers. It should be noted that all of the above- 
described interfaces will be described in greater detail 
below. 

[0027] Referring to Figure 4, there is shown a sche- 
matic diagram of a versatile electronic bill presentment 
and payment system 50 in accordance with the present 
invention. The system 50 comprises a user entity 52, an 
aggregator entity represented as a banking entity 54, a 
billing entity 56, and an electronic payment and cus- 
tomer service (EPCS) entity 58. It should be understood 
that the aggregator entity could be a portal, stock broker 
or other type entity if desired. For purposes of this 
detailed description, the user entity 52, the banking 
entity 54, the billing entity 56, and the EPCS entity 58 
are each distributed database entities 30 as defined 



above. Thus, the user entity 52, the banking entity 54, 
the billing entity 56, and the EPCS entity 58 each has a 
database component 32, an internal message interface 
34, an external message interface 36, a partner mes- 

5 sage interface 38, and a customer care message inter- 
face 40. It should be noted, however, that the user entity 
52, the banking entity 54, the billing entity 56, and the 
EPCS entity 58 are not required to have a database 
component 32, an internal message interface 34, an 

10 external message interface 36, a partner message 
interface 38, and a customer care message interface 
40. That is, the user entity 52, the banking entity 54, the 
billing entity 56, and the EPCS entity 58 are only" 
required to have an internal message interface 34 so 

15 that communications can take place between each 
entity. 

[0028] At this point it should be noted that, although 
only a single user entity 52, banking entity 54, billing 
entity 56, and EPCS entity 58 is shown in the system 

20 50, it is common to have a plurality of such entities in an 
actual versatile electronic bill presentment and payment 
system in accordance with the present invention. 
[0029] As previously described, an internal mes- 
sage interface 34 defines messages that are used to 

25 communicate and query data between distributed data- 
base entities. Thus, since the user entity 52, the bank- 
ing entity 54, the billing entity 56, and the EPCS entity 
58 are all distributed database entities, they all commu- 
nicate through internal message interfaces 34. The 

30 communications are performed over interconnections 
60, which can be electrical wire, optical fiber, or micro- 
wave-based interconnections. 

[0030] At this point it should be noted that each 
internal message interface 34, as well as each external 

35 message interface 36, partner message interface 38, 
and customer care message interface 40, can be imple- 
mented using any number of existing message-based 
communication systems such as, for example, a TCP/IP 
message-based communication system running on the 

40 infrastructure of the internet. Alternatively, the internal 
message interfaces 34, the external message interfaces 
36, the partner message interfaces 38, and the cus- 
tomer care message interfaces 40 could be imple- 
mented with proprietary messaging software on a 

45 private network or intranet. It should also be noted that 
there are no requirements as to the nature of the mes- 
saging protocol, or any middleware used to support the 
messaging. 

[0031] The user entity 52 is typically a personal 
so computer (PC) that is directly connected to the system 
50, or is connected to the system 50 through a network 
server. Thus, the database component 32 associated 
with the user entity 52 can be located on the PC (e.g., a 
traditional "fat" client), or on the network server (e.g., an 
55 HTML browser client). It should be noted that the data- 
base component 32 associated with the user entity 52 
can also be located in one of the other distributed data- 
base entities, which can download data to the user 
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entity 52 (e.g., a Java client). It should also be noted that 
the database component 32 associated with the user 
entity 52 can be distributed among all three of the 
above-listed locations, owing to the distributed nature of 
each database component 32. Thus, each database 
component 32 should not be thought of as a single, 
monolithic database. Rather, each database compo- 
nent 32 is better described as a distributed repository of 
data categorized by the entity that "owns - the data. 
[0032] Wherever it is located, the database compo- 
nent 32 associated with the user entity 52 stores data 
that is related to the type of user interface (Ul) that is 
being presented to a subscriber of the system 50. For 
example, the database component 32 associated with 
the user entity 52 can store data that is related to the 
particular type of presentation technology being used 
(e.g., a "fat" client, an HTML browser client, or a Java 
client), a specific application, or a particular version. 
The database component 32 associated with the user 
entity 52 can also store data that is related to a particu- 
lar computing session such as, for example, the exist- 
ence of a computing session and/or the duration of a 
computing session. The database component 32 asso- 
ciated with the user entity 52 can further store sub- 
scriber authentication data, which is described in detail 
below. 

[0033] The main function of the user entity 52 is to 
build a Ul using data obtained from the other distributed 
database entities, and then present the Ul to a sub- 
scriber of the system 50. The presentation of the Ul to a 
subscriber is dependent upon the particular type of 
presentation technology being used (e.g., a "fat" client, 
an HTML browser client, or a Java client). For example, 
a Ul for a Java client requires that presentation data be 
downloaded from one of the other distributed database 
entities. 

[0034] Other functions of the user entity 52 include 
storing certain data locally so as to facilitate off-line edit- 
ing and viewing, maintaining a state in a connectionless 
environment (e.g., an HTTP environment), and sensing 
the availability of software updates and managing their 
subsequent application. All of these functions depend 
on the nature of the client (e.g., a "fat" client, an HTML 
browser client, or a Java client). As previously indicated, 
another function of the user entity 52 includes storing 
subscriber authentication data (e.g., a security ticket) 
that is used to gain access to other distributed database 
entities in the system 50. 

[0035] The banking entity 54, which is typically an 
Fl such as, for example, a bank, is generally viewed as 
a primary point of presence for a subscriber to the sys- 
tem 50, typically providing an appearance of aggrega- 
tion to the subscriber. This view is held primarily due to 
the trust that consumers typically place in a bank brand, 
and the fact that bank customers who already bank 
online are also likely to want to receive bills online. 
Thus, in the following discussion, the banking entity 54 
is assumed to be the aggregator of the system 50. It 



should be noted, however, that any one of the other enti- 
ties could also be the aggregator of the system 50 in 
accordance with the present invention. There are sev- 
eral factors which can be used to determine aggregator 

5 status such as, for example, market clout. 

[0036] The banking entity 54 typically gains access 
to the system 50 through a network server. Thus, the 
database component 32 associated with the banking 
entity 54 can be located in the network server. It should 

10 be noted that the database component 32 associated 
with the banking entity 54 can also be located in a sys- 
tem associated with the banking entity 54 such as, for 
example, a DDA system. Such a DDA system could be 
accessed through the external message interface 36 of 

15 the banking entity 54, as described in detail below. It 
should further be noted that the database component 
32 associated with the banking entity 54 can also be 
located in one of the other distributed database entities, 
or be distributed among many of the above-mentioned 

20 locations, owing to the distributed nature of each data- 
base component 32. 

[0037] Wherever it is located, the database compo- 
nent 32 associated with the banking entity 54 stores 
bank-specific subscriber profile data profile such as, for 

25 example, subscriber names and addresses and sub- 
scriber account numbers. The database component 32 
associated with the banking entity 54 can also store 
account information such as, for example, static 
account information (e.g., lease rate, principle), and 

30 dynamic account information (e.g., balance). The data- 
base component 32 associated with the banking entity 
54 can further store profile data specifically associated 
with the Fl such as, for example, graphics, business 
rules, banking-related transaction histories, and aggre- 

35 gation relationships such as those between the Fl and 
billers. 

[0038] Since it is likely that the system 50 will be 
used with existing banking systems such as, for exam- 
ple, an existing DDA system, one of the main functions 

40 of the banking entity 54 is the continuation of current 
banking and bill payment functionality including the 
maintaining of customer profiles and already existing 
interfaces. In its role as aggregator, the banking entity 
54 also provides data to the user entity 52 to be used for 

45 the creation of a navigation portion of a Ul. For an HTML 
browser client, this data would be used to create a nav- 
igation frame, but not a content specific frame. It should 
be noted that the banking entity 54 can also provide 
data to the user entity 52 to be used for the creation of a 

so Ul for traditional banking and bill payment. 

[0039] Since the banking entity 54 is generally 
viewed as the primary point of presence for a subscriber 
to the system 50, the banking entity 54 also functions as 
the likely, but not exclusive, entry point for subscriber 

55 sign-on. Thus, the banking entity 54 typically controls 
the sign-on and authentication procedures for subscrib- 
ers through the user entity 52. It should be noted that 
the banking entity 54 typically works in conjunction with 
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the EPCS entity 58 in controlling the authentication pro- 
cedure, as described in detail below. 
[0040] Another function of the banking entity 54 
includes tracking bank related events and storing them 
in an event tracking database, which is typically associ- 
ated with the EPCS entity 58, as also described in detail 
below. 

[0041 J The billing entity 56 is typically a biller such 
as, for example, a utility company. The billing entity 56 
typically gains access to the system 50 through a net- 
work server. Thus, the database component 32 associ- 
ated with the billing entity 56 can be located in the 
network server. It should be noted that the database 
component 32 associated with the billing entity 56 can 
also be located in a system associated with the billing 
entity 56 such as, for example, a legacy billing system. 
Such a legacy billing system could be accessed through 
the external message interface 36 of the billing entity 
56, as described in detail below. It should further be 
noted that the database component 32 associated with 
the billing entity 56 can also be located in one of the 
other distributed database entities, or be distributed 
among many of the above-mentioned locations, owing 
to the distributed nature of each database component 
32. 

[0042] Wherever it is located, the database compo- 
nent 32 associated with the billing entity 56 stores biller- 
specific subscriber profile data such as, for example, 
subscriber names and addresses and subscriber 
account numbers and types (e.g., business vs. residen- 
tial phone line). The database component 32 associ- 
ated with the billing entity 56 also stores billing data for 
use by the user entity 52 in building the Ul for the sub- 
scriber. The billing data can include bill availability data, 
detailed billing data, ads and other cross-sale displays 
and links, and bill payment terms and conditions. 
[0043] The database component 32 associated 
with the billing entity 56 can also store biller transaction 
history such as, for example, bill data manipulation 
(e.g., viewing, searching, sorting), and cross-sell 
events. The database component 32 associated with 
the billing entity 56 can further store biller profile data 
such as, for example, graphics, business rules, and 
relationships with aggregators such as banks. 
[0044] The main function of the billing entity 56 is to 
provide billing data to the user entity 52 for use in creat- 
ing the Ul for the subscriber. The billing entity 56 also 
provides bill availability data to an aggregator database, 
whether it is located in the banking entity 54, the EPCS 
entity 58, or another entity, to provide notice of bill avail- 
ability to subscribers. The billing entity 56 can also 
access legacy billing systems through the external mes- 
sage interface 36 of the billing entity 56, as indicated 
above. 

[0045] Another function of the billing entity 56 
includes tracking biller-related events and storing them 
in an event tracking database, which is typically associ- 
ated with the EPCS entity 58, as described in detail 



below. 

[0046] The EPCS entity 58 can generally be 
described in terms of a data processing system 70, 
such as shown in Figure 5. The data processing system 

5 70 preferably comprises at least one processor (P) 72, 
memory (M) 74, and input/output (I/O) interface 76, 
which are connected to each other by a bus 78, for 
implementing the functions of the EPCS entity 58, as 
described in detail below. 

10 [0047] Referring again to Figure 4, the EPCS entity 
58 typically gains access to the system 50 through a 
network server. Thus, the database component 32 
associated with the EPCS entity 58 can be located in " 
the network server. It should be noted that the database 

is component 32 associated with the EPCS entity 58 can 
also be located in a system associated with the EPCS 
entity 58 such as, for example, a legacy aggregating 
system. Such a legacy aggregating system could be 
accessed through the external message interface 36 of 

20 the EPCS entity 58, as described in detail below. It 
should further be noted that the database component 
32 associated with the EPCS entity 58 can also be 
located in one of the other distributed database entities, 
or be distributed among many of the above-mentioned 

25 locations, owing to the distributed nature of each data- 
base component 32. 

[0048] Wherever it is located, the database compo- 
nent 32 associated with the EPCS entity 58 stores bill 
payment-specific subscriber profile data such as, for 

30 example, subscriber names and addresses, subscriber 
DDA account numbers, and subscriber credit ratings. 
The database component 32 associated with the EPCS 
entity 58 also stores bill payment warehouse data such 
as, for example, user-specific payees, single occurrence 

35 payments, and recurring payments/models. 

[0049] As previously described, both the banking 
entity 54 and the billing entity 56 track and store events 
in an event tracking database. This event tracking data- 
base is typically located in the database component 32 

40 associated with the EPCS entity 58. The event tracking 
data that is stored typically comprises event summaries 
and links to other databases, perhaps residing at other 
entities, which provide event details and/or an audit trail. 
[0050] The database component 32 associated 

45 with the EPCS entity 58 also stores bill payment trans- 
action histories, and system subscriber profile data 
such as, for example, metadata about subscribers and 
metadata about subscribers' relationships to other enti- 
ties (e.g., a list of billers that a subscriber has enabled). 

so The database component 32 associated with the EPCS 
entity 58 further stores billing-related profile information 
on the system aggregator and billers such as, for exam- 
ple, metadata about billing arrangements (e.g., flat rate, 
per subscriber, event-driven, etc.), and aggregation 

55 data such as, for example, new bill availability and mes- 
sages or special announcements available from the bill- 
ing entity 56. The database component 32 associated 
with the EPCS entity 58 still further stores security data 
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such as, for example, required sign-on information and 
macro-level authorizations. The database component 
32 associated with the EPCS entity 58 additionally 
stores customer service data such as, for example, 
FAQ's, Fl and biller contact information, and problem 
resolution data. 

[0051] The EPCS entity 58 is the glue that holds the 
distributed database entities together. The EPCS entity 
58 accomplishes this by functioning as an integration 
agent by maintaining bill payment profiles and ware- 
house data, aggregating bill availability and status data 
(but typically not bill content or presentation), and main- 
taining an event tracking database (or audit trail) that 
can be accessed by all of the database entities. Also, in 
order to facilitate a single point of sign-on, the EPCS 
entity 58 functions as the authentication gate keeper. 
This does not mean to imply that the EPCS entity 58 
necessarily maintains user identification numbers 
and/or passwords. However, it does imply that the 
EPCS entity 58 accepts sign-on requests and may, if 
desired, dole out authentication "tickets" in response, in 
conjunction with the banking entity as described above. 
Note that the aggregator entity, e.g. the bank entity, may 
choose to take total responsibility for authentication of 
the user; in which case, the EPCS entity 58 trusts the 
aggregator entity to verify the user credentials. 
[0052] It should be noted that, like user identifica- 
tion numbers and passwords, other data elements, like 
event details, may end up being virtually aggregated by 
the EPCS entity 58, but may still physically reside in a 
distributed manner across several of the database enti- 
ties. 

[0053] It should also be noted that the EPCS entity 
58 may also route e-mail messages to and from the var- 
ious database entities, as well as store e-mail mes- 
sages sent to and from the various database entities. 
[0054] As previously described, an internal mes- 
sage interface 34 defines messages that are used to 
communicate and query data between distributed data- 
base entities. As also previously described, each inter- 
nal message interface 34 can be implemented using 
any number of existing message-based communication 
systems, or with proprietary messaging software on a 
private network or intranet. Furthermore, the message 
specification or file format can be either standard (i.e., 
open) or proprietary. With this mind, the following types 
of messages are examples of messages which may be 
employed to implement an internal message interface 
34 in accordance with the present invention. 
[0055] Depending upon the nature of the presenta- 
tion technology being used (e.g., a "fat" client, an HTML 
browser client, or a Java client), the user entity 52 may 
need to process an internal message to store a security 
ticket for later use in gaining access to other distributed 
database entities in the system 50. The user entity 52 
may also need to process an internal message to 
update any resident software. The user entity 52 may 
further need to process an internal message containing 



various types of information (assuming a push model). 
The user entity 52 may additionally need to process 
internal e-mail messages such as, for example, those 
for receiving data from other database entities. 

5 [0056] The banking entity 54 will process an inter- 
nal message to add/update/delete/retrieve Fl branding 
information, as well as an internal message to 
add/update/delete an entry from a list of billers that have 
been aggregated. The banking entity 54 will also proc- 

w ess an internal message to activate a subscriber for 
home banking via a messaging protocol, which can be 
an existing messaging protocol such as, for example, 
OFX or a batch process. The banking entity 54 will-fur- 
ther process an internal message to query/update bank 

is subscriber profile data for purposes of customer care. 
The banking entity 54 will still further process an internal 
message to query bank transaction history for customer 
care and for linking to the event tracking database. The 
banking entity 54 will still further process an internal 

20 message to retrieve a list of billers available under the Fl 
sponsor umbrella. An alternative to this is to place the 
list of billers available under the Fl sponsor umbrella in 
an aggregation database. However, placing the list of 
billers available under the Fl sponsor umbrella allows 

25 the EPCS entity 58 to tailor the list by Fl sponsor. The 
banking entity 54 will additionally process internal e- 
mail messages such as, for example, those for sending 
data to other database entities, receiving data from 
other database entities, and broadcasting data to other 

30 database entities. 

[0057] The billing entity 56 will process an internal 
message to add/update/delete/retrieve biller branding 
information, as well as an internal message to activate 
a subscriber for electronic bill presentment via a mes- 

35 saging protocol, which can be an existing messaging 
protocol such as, for example, OFX or a batch process. 
The billing entity 56 will also process an internal mes- 
sage to retrieve bill availability data, retrieve bill detail 
data, and retrieve bill presentation specifications orcon- 

40 tent. For example, the retrieved data could be URL links 
to ads and notices, HTML data, or OFX data. The billing 
entity 56 will further process an internal message to 
query/update biller subscriber profile data for purposes 
of customer care. The billing entity 56 will still further 

45 process an internal message to query biller transaction 
history for customer care and for linking to the event 
tracking database. The billing entity 56 will additionally 
process internal e-mail messages such as, for example, 
those for sending data to other database entities, 

so receiving data from other database entities, and broad- 
casting data to other database entities. 
[0058] The EPCS entity 58 will process internal 
event tracking messages. Such event tracking mes- 
sages are used to gain access to two types of informa- 

55 tion in the event tracking database: summary data and 
a link to another database entry that can provide more 
detail. Such detail includes subscriber enrollment data, 
subscriber service activation data (e.g., biller, bill pay- 
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ment, banking, etc.), sign-on data, bill availability data, 
bill viewed data, bill payment generated data (optionally 
associated with presented bill data), subsequent bill 
payment events data (e.g., submitted, processed, failed, 
cleared, remittance received by biller, etc.), cross-sell 
events data (e.g., ad/offer viewed, ad/offer clicked, prod- 
uct/service purchased), terms & conditions viewed 
data, email created/read/ deleted data. 
[0059] The EPCS entity 58 will also process an 
internal messages related to subscriber profile data 
such as, for example, to add/modify/delete/read sub- 
scriber profile data, often as a function of the events 
listed above (e.g., enrollment, activation, etc.). 
[0060] The EPCS entity 58 will also process inter- 
nal security messages. Such internal security mes- 
sages may relate to authentication, which result in the 
EPCS entity 58 issuing a security ticket. It should be 
noted that an authentication request does not have to 
come as a result of a subscriber "surfing'' to the network 
server of the banking entity 54. It may be initiated if a 
subscriber tries to gain access to the billing entity 56, 
and thereby not even contacting the banking entity 54. 
The point being that with a security ticket a subscriber is 
generally allowed to freely traverse any database entity 
in the system 50 without going through repeated sign- 
on procedures. 

[0061] An internal security message may also 
relate to macro-level authorization, wherein a security 
ticket may contain the credentials to allow a subscriber 
access to a particular billing entity, but doesnt address 
micro-level authorization issues such as allowed opera- 
tions. 

[0062] An internal security message may also 
relate to getting a security ticket without authentication. 
Such a message will originate from a trusted party (e.g., 
an Fl performing its own authentication). Therefore, a 
security ticket is provided without performing an authen- 
tication. 

[0063] It should be noted that the use of a security 
ticket enables, but does not mandate, a single sign-on 
procedure. In other words, a database entity such as, 
for example, the billing entity 56 may, for whatever rea- 
son, require additional authentication information. 
[0064] The EPCS entity 58 will further process 
internal messages relating to aggregation data. For 
example, an EPCS entity 58 will process an internal 
message to create a link to summary or detailed bill 
information, or to create a link to message, notice, ad, or 
some other kind of non-bill information that is available 
from the billing entity 56. 

[0065] The EPCS entity 58 will still further process 
an internal message to query/update bill payment trans- 
action history for purposes of customer care. 
[0066] The EPCS entity 58 will additionally process 
internal e-mail messages such as, for example, those 
associated with routing e-mail, picking-up e-mail, and 
querying and e-mail mailbox. 

[0067] The EPCS entity 58 may also process inter- 



nal messages related to data mining. Such messages 
are handled very carefully with respect to privacy, per- 
haps even providing an ACL or other mechanisms to 
ensure privacy. The results of such messages may be 

5 delivered out of band (e.g., by batch). 

[0068] As previously described, an external mes- 
sage interface 36 defines messages that are used to 
communicate and query data between a given distrib- 
uted database entity 30 and any existing system(s) that 

10 are directly related to the given distributed database 
entity 30. As also previously described, each external 
message interface 36 can be implemented using any . 
number of existing message-based communication sys- 
tems, or with proprietary messaging software on a pri- 

15 vate network or intranet. Furthermore, the message 
specification or file format can be either standard (i.e., 
open) or proprietary. 

[0069] Referring to Figure 6, there is shown a sche- 
matic diagram of the versatile electronic bill present- 

20 ment and payment system 50, along with some 
associated directly related systems. The associated 
directly related systems comprise a desktop database 
80, a DDA system 82, a legacy billing system 84, and a 
legacy remittance system 86. The communications 

25 between the various database entities and their associ- 
ated directly related systems are performed over inter- 
connections 88, which can be electrical wire, optical 
fiber, or microwave-based interconnections. 
[0070] Depending upon the nature of the presenta- 

30 tion technology being used (e.g., a "fat" client, an HTML 
browser client, or a Java client), the user entity 52 may 
need to process an external message in order to com- 
municate with an existing system such as, for example, 
the desktop database 80. To support such a legacy sys- 

35 tern, it may be necessary to implement the external 
message interface 36 of the user entity 52 in the context 
of an existing, and possibly extended, protocol specifi- 
cation, such as Gold, NPC, or OFX. 
[0071] The banking entity 54 will process external 

40 messages to and from an existing system such as, for 
example, the DDA system 82 in order to query and 
update information such as, for example, subscriber 
profile data, subscriber account data, out-of-band (e.g., 
ATM) account activity, and statement history. It's also 

45 conceivable that the banking entity 54 would need to 
interface with other banking systems (e.g., stops). Thus, 
the external message interface 36 of the banking entity 
54 is a key feature of the versatile electronic bill present- 
ment and payment system 50. 

so [0072] The billing entity 56 will process external 
messages to and from an existing system such as, for 
example, the legacy billing system 84 in order to query 
and update information such as, for example, sub- 
scriber profile data, subscriber account data, account 

55 activity, and statement history. Most of this data is indus- 
try, if not biller, specific. Thus, the external message 
interface 36 of the billing entity 56 is a key feature of the 
versatile electronic bill presentment and payment sys- 
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tem 50. 

[0073] The EPCS entity 58 will process external 
messages to and from an existing system such as, for 
example, the legacy remittance system 86. The legacy 
remittance system 86 could be, for example, ACH, RPP, s 
RPS, or Direct Send. 

[0074] As previously described, a partner message 
interface 38 defines messages that are used to commu- 
nicate and query data between a given distributed data- 
base entity 30 and any existing system(s) that are 10 
indirectly related to the given distributed database entity 
30. As also previously described, each partner mes- 
sage interface 38 can be implemented using any 
number of existing message-based communication sys- 
tems, or with proprietary messaging software on a pri- is 
vate network or intranet. Furthermore, the message 
specification or file format can be either standard (i.e., 
open) or proprietary. 

[0075] Referring to Figure 7, there is shown a sche- 
matic diagram of the versatile electronic bill present- 20 
ment and payment system 50, along with some 
associated indirectly related systems. The associated 
indirectly related systems comprise a personal finance 
system 90, a banking system 92, an established billing 
aggregator 94, and an alternative bill presentment and 25 
payment system 96. The communications between the 
various database entities and their associated indirectly 
related systems are performed over interconnections 
98, which can be electrical wire, optical fiber, or micro- 
wave-based interconnections. 30 
[0076] Depending upon the nature of the presenta- 
tion technology being used (e.g., a "fat" client, an HTML 
browser client, or a Java client), the user entity 52 may 
need to process a partner message in order to commu- 
nicate with a partner such as, for example, the personal 35 
finance system 90. The personal finance system 90 
could be, for example, a personal financial manager 
(PFM) software package such as, for example, Quicken 
or Money. 

[0077] The banking entity 54 will process partner 40 
messages to and from a partner such as, for example, 
the banking system 92. 

[0078] The billing entity 56 will process partner 
messages to and from a partner such as, for example, 
the established billing aggregator 94. Such a partner 45 
relationship may be required if a large group of sub- 
scribers are using the established billing aggregator 94, 
and thereby have the leverage to demand that all of their 
bills come through the established billing aggregator 94. 
The established billing aggregator 94 is essentially so 
treated as a proxy for the billers that it represents. Thus, 
subscribers to the established billing aggregator 94 will 
have equal footing as subscribers to the present system 
50. This means that subscribers to the established bill- 
ing aggregator 94 will receive the same event tracking, 55 
customer service, and payment processing functionality 
as subscribers to present system 50. Of course, to gain 
the additional functionality provided by the present sys- 



tem 50, the established billing aggregator 94, or some- 
one acting on their behalf, will need to provide the same 
programming support that is required of any biller par- 
ticipating in the present system 50. 
[0079] To present a bill generated by the estab- 
lished billing aggregator 94, the present system 50 
would, for example, receive bill availability data and the 
URL of a web server of the established billing aggrega- 
tor 94, and the billing entity 56 would then point to the 
web server of the established billing aggregator 94 to 
get an HTML presentation of detailed bill data. In this 
scenario, the partner message interface 38 would be 
essentially the same as an internal message interface 
34, but possibly with added bulk transfer capability. 
[0080] The EPCS entity 58 will process partner 
messages to and from a partner such as, for example, 
the alternative bill presentment and payment system 96. 
Such a partner relationship may be required if a billing 
entity 56 has a subscriber base that is split between 
using the present system 50 and the alternative bill pre- 
sentment and payment system 96. in such a scenario, 
the present system 50 could function as a billing aggre- 
gator for the alternative bill presentment and payment 
system 96, and vice-versa. However, the alternative bill 
presentment and payment system 96 and its subscrib- 
ers would not receive any of the benefits of the messag- 
ing functionality provided by the present system 50. 
Only the minimum amount of functionality would be pro- 
vided. That is, the partner message interface 38 would 
only provide what is required to present bills through the 
alternative bill presentment and payment system 96, 
and not offer any of the advantages provided by the 
present system 50. The goal being to have the billing 
entity 56 encourage all of its subscribers to access bills 
through the present system 50. 
[0081] It should be noted that the EPCS entity 58 
will typically require the capabilities of a billing entity 56 
in order to present bills to and from the alternative bill 
presentment and payment system 96. 
[0082] As previously described, a customer care 
message interface 40 defines messages that are used 
to communicate and query data between a given distrib- 
uted database entity 30 and a customer care entity. As 
also previously described, each customer care mes- 
sage interface 40 can be implemented using any 
number of existing message-based communication sys- 
tems, or with proprietary messaging software on a pri- 
vate network or intranet. Furthermore, the message 
specification or file format can be either standard (i.e., 
open) or proprietary. 

[0083] Referring to Figure 8, there is shown a sche- 
matic diagram of the versatile electronic bill present- 
ment and payment system 50, along with some 
associated customer care entities. The associated cus- 
tomer care entities comprise a user entity self service 
center 100, a banking entity customer service center 
1 02, a billing entity customer service center 1 04, and an 
EPCS customer service center 106. The communica- 
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tions between the various database entities and their 
associated customer care entities are performed over 
interconnections 108, which can be electrical wire, opti- 
cal fiber, or microwave-based interconnections. 
[0084] Depending upon the nature of the presenta- 5 
tion technology being used (e.g., a "fat" client, an HTML 
browser client, or a Java client), the user entity 52 may 
need to process a customer care message in order to 
communicate with a customer care entity such as, for 
example, the user entity self service center 100. The 10 
user entity self service center 100 could be, for exam- 
ple, a self service diagnostic tool. 
[0085] The banking entity 54 will process customer 
care messages from a customer care entity such as, for 
example, the banking entity customer service center is 
102. A customer care message may be a request for 
data or a request to modify existing data. The banking 
entity 54 will process such customer care messages by 
providing the requested data or providing a confirmation 
that the existing data has been modified, respectively, to 20 
the banking entity customer service center 102. The 
banking entity customer service center 1 02 could be, for 
example, a third party telemarketing group that is 
allowed access to banking and overall system data in 
order to provide feedback to system subscribers. 25 
[0086] The billing entity 56 will process customer 
care messages from a customer care entity such as, for 
example, the billing entity customer service center 104. 
A customer care message may be a request for data or 
a request to modify existing data. The billing entity 56 30 
will process such customer care messages by providing 
the requested data or providing a confirmation that the 
existing data has been modified, respectively, to the bill- 
ing entity customer service center 1 04. The billing entity 
customer service center 104 could be, for example, a 35 
third party telemarketing group that is allowed access to 
billing and overall system data in order to provide feed- 
back to system subscribers. 

[0087] The EPCS entity 58 will process customer 
care messages from a customer care entity such as, for 40 
example, the EPCS entity customer service center 106. 
A customer care message may be a request for data or 
a request to modify existing data. The EPCS entity 58 
will process such customer care messages by providing 
the requested data or providing a confirmation that the 45 
existing data has been modified, respectively, to the 
EPCS entity customer service center 106. The EPCS 
entity customer service center 106 could be, for exam- 
ple, a third party telemarketing group that is allowed 
access to event and overall system data in order to pro- st 
vide feedback to system subscribers. 
[0088] It should be noted that all of the customer 
care entities described above could be consolidated 
into a centralized customer service center 110, as 
shown in Figure 9. In such a scenario, each of the data- st 
base entities would process customer care messages 
to and from the centralized customer service center 110 
similar to as described above. The communications 



between the various database entities and the central- 
ized customer service center 110 would be performed 
over interconnections 1 1 2, which can be electrical wire, 
optical fiber, or microwave-based interconnections. 
[0089] Referring to Figures 10-15, there are shown 
flowchart diagrams of data and message flows between 
the various entities within the system 50. These flow- 
chart diagrams assume that the user entity 52 is an 
HTML browser client, the banking entity 54 is the pri- 
mary point of presence for a subscriber to the system 
50, the billing entity 56 controls bill presentment, and 
the EPCS entity 58 controls bill payment. 
[0090] In Figure 10, a subscriber at the user entity* 
52 accesses the web site of the banking entity 54 in step 
200. In return, the banking entity 54 presents a branded 
interface to the user entity 52, including a sign-on 
request prompt in step 202. Figure 1 6 shows an exam- 
ple of such a branded interface 120, wherein the sign- 
on request prompt includes a username field 122 and a 
password field 124. 

[0091] In Figure 11, the user entity 52 submits a 
sign-on request with authentication credentials in steps 
204. The banking entity 54 messages the EPCS entity 
58 with the authentication credentials of the subscriber 
and the event is logged in step 206. The EPCS entity 58 
provides a security ticket to the banking entity 54 in step 
208. The banking entity 54 delivers the security ticket to 
the user entity 52 and presents its "home page" to user 
entity 52 in step 210. Figure 17 shows an example of 
such a home page 130, which includes a "view bills" 
icon 132, a "view checking account" icon 134, and a 
"view savings account" icon 136. 
[0092] It should be noted that either the EPCS 
entity 58 or the banking entity 54 could perform the 
authentication procedure, but in either case the event is 
still logged in the event tracking database. 
[0093] In Figure 12, the subscriber selects the View 
bills" icon 132 in step 212. The banking entity 54 mes- 
sages the EPCS entity 58 with an aggregation data 
request and the event is logged in step 214. The EPCS 
entity 58 presents aggregation data of new bill availabil- 
ity to user entity 52 in step 216. Figure 18 shows a first 
modified home page 140 having an EPCS entity frame 
142 presenting the new bill availability data, which 
includes an "electric bill" icon 144, a "gas bill" icon 146, 
a "phone bill" icon 148, a "cable bill" icon 150, a "credit 
card bill" icon 152, and an "all bills" icon 154 which 
allows all bills to be presented simultaneously, albeit in 
separate frames. 

[0094] In Figure 13A, the subscriber selects the 
"gas bill" icon 146 and is linked to the billing entity 56 
along with the security ticket in step 218. The billing 
entity 56 messages the EPCS entity 58 to log the View 
bill" request event in step 220. The billing entity 56 
presents detailed bill data to the user entity 52 in step 
222. Figure 19 shows a second modified home page 
160 having a billing entity frame 162 presenting the 
detailed bill data, which includes the subscriber name, 
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subscriber address, account number, usage, and cost, 
and a "pay bill" icon 164. 

[0095] In Figure 14, the subscriber selects the "pay 
bill" icon 164 and messages the EPCS entity 58 with a 
forward dated pay bill request so the event is logged in 5 
step 224. The EPCS entity 5B messages the billing 
entity 56 with a pay bill request notification along with a 
bill identification number in step 226. 
[0096] In Figure 1 5, the EPCS posts a debit with the 
banking entity 54 and the event is logged in step 228. w 
The EPCS entity 58 then remits a payment to the billing 
entity 56 and the event is logged in step 230. 
[0097] Figure 1 3B can be substituted for Figure 1 3A 
in the above-described sequence of flowchart diagrams 
to show how detailed bill data can be provided by the 15 
established billing aggregator 94 through the partner 
message interface 38 of the billing entity 56. In Figure 
13B, the subscriber again selects the "gas bill" icon 146 
and is linked to the billing entity 56 along with the secu- 
rity ticket in step 232. The billing entity 56 again mes- 20 
sages the EPCS entity 58 to log the "view bill" request 
event in step 234. However, in this case, detailed bill 
data is available only from the established billing aggre- 
gator 94. Thus, the billing entity 56 accesses the estab- 
lished billing aggregator 94 through its partner message 25 
interface 38 in step 236. In response, the established 
billing aggregator 94 provides detailed bill data to the 
billing entity 56 in step 238. The billing entity 56 then 
presents the detailed bill data to the user entity 52 in 
step 240. 30 
[0098] It should be noted that, in an alternative 
embodiment, the established billing aggregator 94 
could present the detailed bill data directly to the user 
entity 52. 

[0099] Figure 13C can be substituted for Figure 35 
13A in the above-described sequence of flowchart dia- 
grams to show how detailed bill data can be provided by 
the alternative bill presentment and payment system 96 
through the partner message interface 38 of the EPCS 
entity 58. In Figure 1 3C, the subscriber selects the "gas 40 
bill" icon 146 and is linked back to the EPCS entity 58 
along with the security ticket and the event is logged in 
step 242. In this case, detailed bill data is available only 
from the alternative bill presentment and payment sys- 
tem 96. Thus, the EPCS entity 58 accesses the alterna- 45 
tive bill presentment and payment system 96 through its 
partner message interface 38 in step 244. In response, 
the alternative bill presentment and payment system 96 
provides detailed bill data to the EPCS entity 58 in step 
246. The EPCS entity 58 then presents the detailed bill so 
data to the user entity 52 in step 248. 
[0100] It should be noted that, as previously 
described, the EPCS entity 58 will typically require the 
capabilities of a billing entity 56 in order to present bills 
to and from the alternative bill presentment and pay- 55 
ment system 96. Alternatively, it should be noted that 
detailed bill data can be provided by the alternative bill 
presentment and payment system 96 through the part- 



ner message interface 38 of the billing entity 56 in a 
manner similar to that as described in Figure 13B. 
[01 01 ] Referring to Figure 20, there is shown a flow- 
chart diagram of data and message flows between the 
centralized customer service center 1 1 0 and the various 
entities within the system 50. A subscriber 1 70 contacts 
the centralized customer service center 110 regarding a 
bill payment in step 250. The centralized customer serv- 
ice center 1 10 accesses the event tracking database in 
the EPCS entity 58 to see if a view bill, pay bill, remit 
payment, or debit posting event has been logged in step 
252. If more detailed information regarding, for exam- 
ple, the posting of a debit for a bill, the centralized cus* 
tomer service center 110 can access the database 
component 32 associated with the banking entity 54, as 
shown in step 254. Similarly, if more detailed informa- 
tion regarding, for example, the remitting of a payment 
for a bill, the centralized customer service center 110 
can access the database component 32 associated with 
the billing entity 56, as shown in step 256. It should be 
noted that, although not shown, the EPCS entity 58 can 
log all of the above-described accesses performed by 
centralized customer service center 1 1 0. 
[0102] As is apparent from the foregoing descrip- 
tion, the system 50 allows a subscriber to interact 
directly with individual billers while retaining the benefits 
of interacting with a single aggregator such as, for 
example, the ability to retain a single authentication and 
log-in procedure and a common bill presentation frame- 
work. The system 50 also allows a subscriber to retain 
the benefits of interacting with a single aggregator while 
allowing the billers and banks to retain certain prefer- 
ences such as, for example, the ability to retain control 
of subscriber-related data and a communication chan- 
nel with each subscriber. 

[01 03] Billers often include promotional information, 
which could include any type of supplemental informa- 
tion with paper bills. Materials containing such informa- 
tion are sometimes referred to as "envelope stuffers". In 
a paper world, it is very difficult to selectively provide 
such supplemental information with only the bills mailed 
to those customers who are most likely to take advan- 
tage of the supplemental information. It is also very dif- 
ficult to selectively avoid mailing supplemental 
information with bills to individual customers, e.g. to 
avoid providing a particular envelop stuffer to some 
selected group of customers. 
[0104] For example, a telephone or other company 
may have certain customers currently using a low level 
of services. The company's market research may show 
that these customers are likely to increase their usage 
based upon a certain type of offer, e.g. a discount plan. 
The company may also have other customers who are 
already at a high level of usage. The company's market 
research may also show that these latter customers are 
likely to remain at a high level of usage without the dis- 
count plan. 

[0105] In such a case, the company wants to make 
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the promotional offering to the low level users but not to 
the high level users. Since the market research shows 
that the high level users will remain high level users 
without the offer, little, if anything, is to be gained and 
much could be lost by providing the discount offer to the 
existing high level users. Accordingly, the present inven- 
tion allows the high level users to be advantageously 
serviced through a third party, such as the EPCS, or at 
a biller network address which is different than a biller 
network address at which the low level users are serv- 
iced. If the servicing is in the nature of bill presentment 
services, only low level users receive a bill presentation 
enriched with the special promotional offering. Because 
only a portion of the customers are serviced from the 
site offering the enriched bill presentment, greater 
resources can be focussed on providing a more satisfy- 
ing bill presentation experience to the lower level users, 
and hence to the users most likely to increase usage 
based on the promotion. The system therefore allows 
resources to be allocated so as to provide the greatest 
potential benefit to the company. 
[0106] Figure 21 depicts the message flow in an 
alternative electronic billing system implementation 
which provides greater flexible in the biller control of the 
servicing of its customers. More particularly, the system 
allows the biller to select those users who will be 
directed to a first network address which is preferably 
although not necessarily, one controlled by the biller, 
and those users who will be directed to some other net- 
work address, e.g. a different network address control- 
led by the biller or some other entity, for servicing. For 
example, different users may be directed to different 
addresses and/or entities for the presentment of a 
detailed bill and/or supplemental information such as 
special offerings. Hence, this alternative system allows 
billers to choose which users will be directed, for exam- 
ple, to a Diner's network address and provided with an 
enriched presentation experience, and which users will 
be serviced by the EPCS or some other entity, or at 
some other biller network address and provided a 
somewhat different presentment experience. 
[0107] The database component 32 associated 
with the billing entity 56 stores a flag or other indicator, 
sometimes referred to as a "magnet", in the biller-spe- 
cific subscriber profile data which indicates those users 
which are to be directed to, for example, the biller for 
presentment of bills or promotional information that sup- 
plements the bill. Users which are not flagged might be 
presented bills and/or general promotional information 
by the EPCS, or some other entity, such as a separate 
bill aggregator or alternative bill presentment and pay- 
ment system. Alternatively, these non-flagged users 
could be presented bills and/or general promotional 
information by the biller, but from a network address dif- 
ferent than the address used to present bills and/or spe- 
cial promotional information to the flagged users. The 
database component 32 associated with the billing 
entity 56 generally continues to store the billing data for 



both the flagged and non-flagged users. However, the 
billing entity also provides the billing data for the non- 
flagged users to the database of another entity if this 
other entity will be presenting bills to non-flagged users. 

5 [01 08] For example, the billing data for non-flagged 
users could be located at the EPCS entity 58, as has 
been previously discussed, if the EPCS will be present- 
ing bills to non-flagged users. In such a case, the billing 
data for the non-flagged users is stored in the database 

10 component 32 of the EPCS entity 58. Whether or not 
the EPCS 58 will be presenting bills to non-flagged 
users, the database component 32 of the EPCS 58 . 
stores one or more flags or other indicators in the biller-' 
specific subscriber profile data to indicate that certain 

is users are to be presented bills and/or promotional infor- 
mation at other than a primary biller network address. 
Of course, if desired, the flags could be used to indicate 
those users which are to be presented bills and/or pro- 
motional information at the primary biller address. In 

20 either case, the flags or other indicators stored in the 
EPCS database component 32 are used to ensure that 
certain users are presented bills and/or promotional 
information by the EPCS or some other entity, or at an 
alternate biller address, and other users are presented 

25 bills and/or promotional information at the primary biller 
or other entity address. 

[0109] Users which are not flagged for the applica- 
ble biller in the EPCS database 32 are, in the preferred 
implementation, directed to the applicable biller primary 

30 network address for presentment of bills and/or promo- 
tional information. However, as noted above, these 
users could, if desired, be directed to an address con- 
trolled by some other entity. Users which are flagged in 
the EPCS database 32 are directed to the EPCS 58 or 

35 some other entity, or perhaps a different biller network 
address than the address to which the non-flagged 
users are directed, for presentment of bills and/or pro- 
motional information. In the preferred implementation, 
users which are not flagged for any billers are always 

40 directed to the applicable billers for presentment of bills 
and/or promotional information. Users which are 
flagged for some billers and not flagged for other billers 
are presented bills and/or promotional information of the 
billers for which they are flagged by the EPCS or at an 

45 alternate biller address, and are presented bills and/or 
promotional information of the billers for which they are 
not flagged by the billers themselves. 
[01 1 0] Figure 22A depicts a database 1 1 70 which is 
stored in the database component 32 associated with 

so the EPCS 58. The database 1170 includes a user list 
1 172, listing users A, B, C.n, and a biller list 1 174, list- 
ing billers 1,2, 3...n. For each user, the database stores 
bill availability information 1176. The information 1176 
may simply indicate that a bill is available or may include 

55 bill summary information, such as the total bill amount. 
For each available bill, a flag or other indicator 1 178 is 
optionally provided. The flag 1 178 identifies the bills of 
those customers which are to be directed to a second- 
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ary network address for presentation of requested bills 
and/or promotional information of a particular biller. The 
flag information may be provided to the EPCS database 
at the time the bill availability information is transmitted 
to the database by the biller. Such transmissions typi- 
cally occur off-line, e.g. in a n on -real -time batch trans- 
mission, but could, if desired, occur in an on-line 
session between the biller and the EPCS. Even in this 
latter case, however, the session between the biller and 
the EPCS would typically occur asynchronously, i.e. as 
a separate session, from the session between the con- 
sumer and the EPCS. If desired, the flag could be pro- 
vided in a communication separate from that 
transmitting the bill availability information. This may be 
advantageous if the network address to which the cus- 
tomer will be sent for bill presentment and/or presenta- 
tion of promotional informaion will not change from 
billing cycle to billing cycle. 

[0111] As shown in Figure 22A, user A has bills 
available from billers 1 and 2. The biller 1 bill availability 
information is associated with a flag. Hence, as will be 
discussed further below, should user A request detailed 
bill information relating to the biller 1 bill or request pay- 
ment of the bill without first requesting to view the bill, 
user A will be directed to a network address other than 
a primary network address of biller 1 for presentment of 
the bill and/or promotional material. On the other hand, 
should user A request detailed bill information relating 
to the biller 2 bill or request payment of the bill without 
first requesting to view the bill, user A will be directed to 
the primary network address of the biller 2 for present- 
ment of the bill and/or promotional information. 
[0112] User B has bills available from billers 1 and 
3. The bill availability information for these bills is not 
associated with a flag. Accordingly, should user B 
request detailed bill information relating to the bill of 
biller 1 or biller 3 or request payment of the bill without 
first requesting to view the bill, user B will be directed to 
the primary network address of the applicable biller for 
presentment of the bill. 

[0113] User C has bills available from billers 2 and 
3. The bilter 2 bill availability information is associated 
with a flag. Hence, should user C request detailed bill 
information relating to the biller 2 bill or attempt to pay 
the bill without first viewing the bill detail, user C will be 
directed to a network address other than a primary net- 
work address of biller 2 for presentment of the bill and/or 
promotional information. On the other hand, should user 
C request detailed bill information relating to the biller 3 
bill or attempt to pay the bill without first viewing the bill 
detail, user C will be directed to the primary network 
address of biller 3 for presentment of the bill and/or pro- 
motional information. 

[0114] It should be noted that none of the bill avail- 
ability information associated with bills of biller 3 are 
shown to be flagged. This reflects a desire by biller 3 to 
have all its customers sent to its primary bill presenta- 
tion address to view detaited bill information and/or pro- 



motional information. 

[0115] As shown in Figure 22B, the EPCS database 
component 32 also stores a database 1180 of network 
addresses 11 84 and 1 186 in association with an identi- 

5 fier 1 1 82 for each of the billers. As depicted, biller 1 has 
a primary network address at URL 1A. This address 
could, for example, be the address of a presentment 
server at the biller's network site. Biller 1 also has a sec- 
ondary network address at URL 1 B. This address could 

w be a network address of a presentment server at a dif- 
ferent entity site, e.g. at the EPCS 58, or a different pre- 
sentment server at the biller's site or a different address 
to a single presentment server at the biller 1 site. 
[0116] Biller 2 has a primary network address at 

is URL 2A. This address could, for example, be the 
address of a presentment server at the biller 2 network 
site. Biller 2 also has a secondary network address at 
URL 2B. As with biller 1, this address could be a net- 
work address of a presentment server at a different 

20 entity site, or a different presentment server at the 
biller's site or a different address to a single present- 
ment server at the biller 2 site. 

[0117] Biller 3 has only a single network address at 
URL 3. This address could be the address of a present- 
's ment server at the biller's network site. Since biller 3 
does not have a secondary network address, all cus- 
tomers of biller 3 are directed to a single presentment 
server for presentment of detailed bill information and/or 
promotional information. 
30 [0118] It will be recognized that, if desired, the 
number of different secondary network addresses for a 
given biller identified in database 1182 could be 
increased to 3 or more. In such a case, different flags, 
each for example representing a different network 
35 address, are used in database 1 1 70 to identify which of 
the multiple secondary addresses a specific customer is 
to be directed for electronic bill and/or promotional infor- 
mation presentation. 

[0119] Turning back to Figure 21, as shown the sub- 

40 scriber selects the "view bills" icon 1 132 in step 1212. 
The banking, or other aggregator, entity 54 messages 
the EPCS entity 58 with an aggregation data request 
and the event is logged in step 1214. The EPCS entity 
58 presents aggregation data of new bill availability to 

45 user entity 52 in step 1216. 

[0120] As shown in Figure 23A, the banking entity 
modified home page 1140A includes an EPCS entity 
frame 1 142A presenting the new bill availability data for 
a first subscriber. Figure 23A is similar to Figure 18, 

so except that the user will be hyperlinked to the biller's pri- 
mary network address to obtain detailed bill data and/or 
promotional information from some of the billers, but will 
be hyperlinked to the biller's secondary network 
address to obtain detailed bill data and/or promotional 

55 information of other of the billers. 

[0121] More particularly, the available bills shown 
on screen 1 140A include an "electric bill" icon 1 144A, a 
"gas bill" icon 1 1 46A, a "phone bill" icon 1 1 48A, a "cable 
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bill" icon 1 150A, a "credit card bill" icon 1 152A, and an 
"all bills" icon 1154A which allows all bills to be pre- 
sented simultaneously, albeit in separate frames. The 
electric and phone bills are shown with one or more 
asterisks to indicate that these bills or associated pro- 
motional material will be provided to the first subscriber 
by the EPCS 58 or biller 56 at a secondary biller net- 
work address, as will be described in detail below, 
rather than by the biller 56 at a primary biller address. 
The asterisk(s) would not actually appear on the screen 
displayed to the user but is shown here to indicate that 
the first subscriber has not been flagged by the billers 
associated with the electric and phone bills so as to aid 
in the understanding of the invention. 
[0122] Figure 23B is similar to Figure 23A but is for 
a second subscriber. The banking entity modified home 
page 1 1 40B includes an EPCS entity frame 1 1 42B pre- 
senting the new bill availability data for the second sub- 
scriber. The available bills shown on screen 1140B 
include an "electric bill" icon 1144B, a "gas bill" icon 
1146B, a "phone bill" icon 1148B, a "cable bill" icon 
1 150B, a "credit card bill" icon 1 152B, and an "all bills- 
icon 1 154B. In the case of Figure 23B, the second sub- 
scriber will be hyperlinked to the biller to obtain his/her 
electric bill and/or promotional information. It should be 
noted that, although both the first and second subscrib- 
ers are billed by the same phone company, the first sub- 
scriber is directed to the EPCS for presentation of its 
phone bill and/or promotional information, and the sec- 
ond subscriber is directed to the biller itself for present- 
ment of its phone bill and/or promotional information. 
The second subscriber will also be hyperlinked to the 
biller to obtain the gas bill and/or associated promo- 
tional information. However, although both the first and 
second subscribers are billed by the same gas utility 
company, the biller network address to which the sec- 
ond subscriber will be linked is different than the biller 
address to which the first subscriber will be linked for 
presentation of their respective gas bills and/or associ- 
ated promotional information. Finally, the second sub- 
scriber will also be hyperlinked to the EPCS 58 to obtain 
its electric bill and/or associated promotional informa- 
tion. Hence, in Figure 23B, the gas and electric bills 
rather than the electric and phone bills, are shown with 
an asterisk(s) to indicate that the second subscriber has 
not been flagged by the electric and gas companies and 
that these bills and/or associated promotional informa- 
tion will be provided to this particular user at a second- 
ary network address by the biller 56 or the EPCS 58, 
rather than by the biller 56 at a primary network 
address. 

[01231 Figure 23C is similar to Figure 23A except 
that the banking entity modified home page 1140C 
includes an EPCS entity frame 1142C presenting the 
new bill availability data, including total bill amounts, for 
the first subscriber. The modified home page 1140C 
can be substituted for the modified home page 1 140A. 
The available bills shown on screen 1140C include an 



"electric bill" icon 1144C, a "gas bill" icon 1146C, a 
"phone bill" icon 1148C, a "cable bill" icon 1150C, a 
"credit card bill" icon 1152C, and an "all bills" icon 
1 154C. A "pay bill" icon 1 155 is also provided so that a 
5 user can request the payment of the bill amount based 
upon a review of only the information presented in 
EPCS frame 1 142C. In the case of Figure 23C, the elec- 
tric and phone bills are shown with one or more aster- 
isks, as in Figure 23A, to indicate that the billers 

10 associated with these bills have not flagged the first 
subscriber. Hence, if the "view bill" icon is clicked-on the 
first subscriber will be hyperlinked as discussed above 
with reference to Figure 23A to the appropriate entity' 
and address to view the detailed bill information and/or 

is associated promotional information. 

[0124] As discussed above with reference to Fig- 
ures 14 and 15, when, after reviewing billing informa- 
tion, detailed or otherwise, the user selects "pay bill", 
the user is directed to the EPCS 58 which communi- 

20 cates with the applicable billing and banking entities to 
process the payment. To perform this function, the data- 
base component 32 associated with the EPCS 58 entity 
is made aware of the total amount of each available bill 
for a user 52. Accordingly, each billing entity 56 must 

25 provide bill summary information, including the total bill 
amount, for each available bill to the aggregator data- 
base, which is preferably but not necessarily located at 
the EPCS entity 58, as has been previously discussed. 
As shown, the database component 32 of the EPCS 

30 entity 58 stores bill summary information for each avail- 
able bill for each user which is accessed and used by 
the EPCS to process payments responsive to the 
receipt of user initiated "pay bill" messages received 
directly from the user or from the user's sponsor. 

35 [01 25] In the case of Figure 23C, the payment proc- 
ess can be initiated by the user directly from the bill 
availability information presented by the EPCS entity 58 
in frame 1142C. However, as noted above, certain bill- 
ers have flagged the first subscriber, thereby indicating 

40 a desire that the first subscriber be directed to those bill- 
ers. Hence, as will be described further below, the sys- 
tem further provides the ability to direct the user to the 
biller or any other desired entity even in those cases 
where the user is offered the option of providing the pay 

45 bill instruction from the EPCS bill availability screen, 
such as in Figure 23C. 

[0126] In Figure 24A, which is similar to Figure 13A, 
the first subscriber selects the "gas bill" icon 1 1 46A and 
is linked to a network address at the billing entity 56, 
so with the security ticket in step 1218A. The billing entity 
56 messages the EPCS entity 58 to log the "view bill" 
request event in step 1220A. The billing entity 56 
presents detailed bill data to the user entity 52 in step 
1222 A. 

55 [0127] In Figure 24B, which is similarto Figure 24A, 
the first subscriber selects the "phone bill" icon 1 148B 
and messages the EPCS 58 for detailed billing data in 
step 1218B. The EPCS entity 58 messages the billing 
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entity 56 to log the 'view bill" request event in step 
1220B. The EPCS entity 58 presents detailed bill data 
to the user entity 52 in step 1222B. 
[0128] In Figure 24C, which is similar to Figure 24A, 
the second subscriber selects the "gas bill" icon 1 146C s 
and is linked to a secondary network address at the bill- 
ing entity 56, with the security ticket in step 1218C. 
Although the billing entity 56 in Figures 24A and 24C 
represent the same gas company, the network address 
of the billing entity, i.e. the gas company, to which the 10 
second subscriber is linked in step 1218C is different 
than the network address to which the first subscriber is 
linked in step 1218A. Thus, in the case of the gas com- 
pany, the biller retains control over all bill presentments 
and simply flags different users so that the EPCS will 15 
provide hyperlinks which direct different users to differ- 
ent biller network addresses as desired by the biller. 
Here again, the billing entity 56 messages the EPCS 
entity 58 to log the "view bill" request event in step 
1220C. The billing entity 56 also presents detailed bill 20 
data to the user entity 52 in step 1222C, however, as will 
be described in greater detail below, the presentations 
made to the subscriber linked to the primary network 
address of the gas company and to the subscriber 
linked to the secondary network address of the gas 25 
company will be different. 

[0129] In Figure 24D, which is similar to Figure 24A, 
the first subscriber selects, e.g. clicks-on, the "pay bill" 
icon 1 155 after highlighting the "gas bill" in the bill sum- 
mary information shown in Figure 23C. Although, as 30 
discussed above, the payment instruction will be proc- 
essed by the EPCS, the first subscriber is automatically 
linked to a network address at the billing entity 56, with 
the security ticket, in step 121 8D. The billing entity 56 
messages the EPCS entity 58 to log the "pay bill" 35 
request event in step 1220D. The EPCS 58 may initiate 
processing of the pay instruction based upon this mes- 
sage from the billing entity 56 or based upon some other 
message, as will be recognized by those skilled in the 
art. The billing entity 56 presents a special promotional 40 
offer to the user entity 52 in step 1 222 D. Hence, even 
though the user has not requested detailed bill informa- 
tion from the biller, the user is forced to the billing entity 
for presentation of promotional information, as may be 
desired by the biller, without presenting the detailed bill. 45 
It will of course be recognized that the first subscriber 
can be forced to any biller whose bill is shown to be 
available in Figure 23C, as may be desirable under the 
circumstances, whenever the user clicks on the "pay 
bill" icon to direct payment of that biller*s bill. so 
[0130] Figure 25A shows a home page 1 1 60A hav- 
ing a billing entity frame 1 1 62A presenting the detailed 
gas bill data to the first subscriber, after a "view bill" 
request. The home page 1160A includes, within frame 
1162A, the subscriber name, subscriber address, 55 
account number, usage, and cost, and a "pay bill" icon 
1164A. As shown in Figure 25A, billing entity frame 
1162A also includes an icon 11 66 A which can be 



clicked on to present special targeted promotional infor- 
mation, e.g. a special discount offer, survey or software 
upgrade etc., to the first subscriber. The first subscriber 
may also be provided with other general promotional 
information, such offers as which are being generally 
made to all gas company customers. Hence, a rich 
presentation is provided to the first subscriber. 
[0131] Figure 25B shows a home page 1 1 60B hav- 
ing an EPCS entity frame 1 1 62B presenting the detailed 
phone bill data to the first subscriber, after a "view bill" 
request. The home page 1160B includes, within frame 
1162B, the same information included in frame 1162A 
of Figure 25A. However, the Figure 25B home page 
1 1 60B does not include the special targeted information 
for presentation to the first subscriber. Rather, the 
EPCS entity frame 1162B only includes an icon 1166B 
which can be clicked on to present general, typically 
untargeted, promotional information, e.g. a general offer 
to install an additional phone line within a facility, to the 
first subscriber. Hence, a more baste presentation is 
provided to the first subscriber. 
[01 32] Figure 25C shows a home page 1 1 60C hav- 
ing a billing entity frame 1162C presenting a description 
of a special promotional offering by the gas company to 
the first subscriber, without the presentation of detailed 
billing information, after a "pay bill" request is entered 
during presentation of the bill availability information. It 
should be noted that the special offering could be pre- 
sented with the bill even though the pay bill request has 
been entered, if so desired. The home page 1160C 
includes, within frame 1 162C, a description of the spe- 
cial offering 1164C, a message indicating the payment 
is being processed, and an icon 1166C which can be 
clicked on to place an order for the offered product. As 
discussed above, a special targeted promotional offer- 
ing might be described or other promotional information 
could, if desired, be presented to the first subscriber. 
The first subscriber may also be presented with a 
description of other offers which are being generally 
made to gas company customers. Hence, a rich presen- 
tation is provided to the first subscriber after a selecting 
"pay bill" from the EPCS presentation shown if Figure 
23C. 

[0133] It will be understood that, in the case of the 
first subscriber, richer, targeted gas, cable and credit 
card bill presentations, and more basic, untargeted 
electric and phone bill presentations are provided by the 
respective billing entities 56. On the other hand, the 
second subscriber receives richer, targeted phone, 
cable and credit card bill presentations, and more basic, 
untargeted electric and gas bill presentations from the 
respective billing entities 56. 

[01 34] At this point it should be noted that while the 
foregoing detailed description was directed to an elec- 
tronic bill presentment and payment technique, any 
number of system types can employ the distributed 
database entities 30 to facilitate distributed data 
accessing within a network in accordance with the 
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present invention. 

[0135] The present invention is not to be limited in 
scope by the specific embodiments described herein. 
Indeed, various modifications of the present invention in 
addition to those described herein, will be apparent to 
those of skill in the art from the foregoing description 
and accompanying drawings. Thus, such modifications 
are intended to fall within the scope of the appended 
claims. 

Claims 



10 



1. A network for electronically presenting bill related 
information, comprising: 

a central network station configured to transmit 
bill availability information identifying available 
bills of a plurality of different billers for a plural- 
ity of different users, information associated 
with each of the identified bills of a respective 
one of the plurality of different billers being 
available at one of a first network address 
associated with the respective biller and a sec- 
ond network address associated with the 
respective biller; and 

a plurality of different user stations, each asso- 
ciated with a respective one of the plurality of 
different users, and configured to receive the 
transmitted bill availability information for its 
associated user and to select one of the identi- 
fied bills; 

wherein a first of the plurality of user stations, 
associated with a first of the plurality of different 
users, is linked to the first network address 
associated with a first of the plurality of different 
billers based on a first bill selection by the first 
user station, and a second of the plurality of 
user stations associated with a second of the 
plurality of user stations associated with a sec- 
ond of the plurality of different users is linked to 
the second network address associated with 
the first biller based on a second bill selection 
by the second user station. 

2. A network according to claim 1 , wherein: 

the identified bill of the first biller for the first 
user is available with supplemental information 
at the first network address, and the identified 
bill of the first biller for the second user is avail- 
able without the supplemental information at 
the second network address. 

3. A network according to claim 1 , wherein: 

the transmitted bill availability information iden- 
tifying the available bill of the first biller for the 
first user includes a hyperlink to the first net- 



work address; and 

the transmitted bill availability information iden- 
tifying the available bill of the first biller for the 
second user includes a hyperlink to the second 
network address. 

4. A network according to claim 1 , wherein: 

the first user station is automatically linked to 
the first network address responsive to the first 
bill selection; and 

the second user station is automatically linked . 
to the second network address responsive to 
the second bill selection. 

5. A network according to claim 1 , further comprising: 

a plurality of different biller stations, each asso- 
ciated with a respective one of the plurality of 
different billers, a first of the plurality of different 
biller stations being associated with the first 
biller; 

wherein the first network address is a network 
address associated with the first biller station; 
and 

wherein the second network address is a net- 
work address associated with the central 
processing station. 



30 6. A network according to claim 1 , wherein: 



each of the plurality of user stations is further 
configured to display the transmitted bill availa- 
bility information, to receive an input of its asso- 
ciated user, and to select one of the identified 
bills based on the received input. 
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7. A network according to claim 1 , wherein: 

the plurality of user stations are further config- 
ured to transmit requests for the bill availability 
information; and 

the central network station is further configured 
to transmit the bill availability information 
responsive to the transmitted requests. 

8. A network according to claim 1 , wherein: 

the bill availability information identifies availa- 
ble bills without identifying an amount of each 
of the bills. 

9. A network according to claim 1 , wherein: 

the bill availability information identifies the 
total amount of each of the available bills; 
each of the plurality of different user stations is 
further configured to select one of the identified 
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bills for payment; 
and 

the first and the second user stations are 
respectively linked to the first and the second 
network addresses based on a bill selection for 
one of viewing and payment of the selected bill. 

10. A network according to claim 1, wherein: 

the information associated with each of the 
identified bills available at the first network 
address is promotional information and the 
information associated with each of the identi- 
fied bills available at the second network 
address is detailed bill information. 

11. A network according to claim 1, further comprising: 

a database configured to store the bill availabil- 
ity information; and 

the central network station is further configured 
to transmit the stored bill availability informa- 
tion. 

12. A method of electronically distributing bill related 
information, comprising the steps of: 

centrally receiving initial requests for bills of a 
plurality of different billers for a plurality of dif- 
ferent users; 

transmitting, responsive to the received initial 
requests, bill availability information, identifying 
available bills of the plurality of different billers 
for the plurality of different users, including a 
first bill of a first of the plurality of different bill- 
ers for a first of the plurality of different users 
and a second bill of the first biller for a second 
of the plurality of different users; 
receiving a first request relating to the identified 
first bill of the first biller at a first network 
address and a second request relating to the 
identified second bill of the first biller at a sec- 
ond network address, different than the first 
network address; and 

transmitting information associated with the 
first bill from the first network address respon- 
sive to the receipt of the first request and infor- 
mation associated with the second bill from the 
second network address responsive to the 
receipt of the second request. 

13. A method according to claim 12, further comprising 
the steps of: 

transmitting a first hyperlink to the first network 
address with the bill availability information 
identifying the first bill; and 
transmitting a second hyperlink to the second 



network address with the bill availability infor- 
mation identifying the second bill; 
wherein the first request is received at the first 
network address via the first hyperlink; 
wherein the second request is received at the 
second network address via the second hyper- 
link. 

14. A method according to claim 12, further comprising 
the steps of: 

generating the first request based on an input 
of the first user; - ■*' 

generating the second request based on an 
input of the second user; 
automatically transmitting the generated first 
request to the first network address; and 
automatically transmitting the second gener- 
ated request to the second network address. 

15. A method according to claim 12, wherein: 

the bill availability information identifies availa- 
ble bills without identifying an amount of each 
of the bills. 

16. A method according to claim 12, wherein: 

the first request is one of a request to pay and 
a request to view the identified first bill and the 
transmitted information associated with the first 
bill includes promotional information; and 
the second request is one of a request to pay 
and a request to view the identified second bill 
and the transmitted information associated with 
the second bill excludes the promotional infor- 
mation. 



17. A method according to claim 12, further comprising 
40 the steps of: 

centrally storing the bill availability information; 
wherein the transmitted bill availability informa- 
tion is the stored bill availability information. 

45 

18. A system for electronically distributing bill related 
information, comprising: 

a memory configured to store identifiers of 
so available bills of a plurality of different billers for 

a plurality of different users, and network 
addresses at which information associated with 
the identified bills is available, including a first 
bill identifier which identifies a first of the avail- 
55 able bills of a first of the plurality of billers for a 

first of the plurality of users and a second bill 
identifier which identifies a second of the avail- 
able bills of the first biller for a second of the 



70 



15 



20 



25 



30 



35 



19 



37 



EP 1 091 330 A2 



3B 



plurality of users; and 

a processor configured to direct the transmis- 
sion of the stored first bill identifier to the first 
user with a first of the network addresses, and 
the transmission of the stored second bill iden- s 
tifier to the second user with a second of the 
network addresses, the first network address 
being different than the second network 
address; 

wherein the information associated with the 10 
first bill is available at the first network address 
and the information associated with the second 
bill is available at the second network address. 

19. A system according to claim 1 8, wherein: is 

the first network address is transmitted as a 
first hyperlink; and 

the second network address is transmitted as a 
second hyperlink. 20 

20. A system according to claim 18, wherein: 

the processor is further configured to receive 
requests for the available bills for the plurality of 25 
users including a first request for the available 
bills for the first user and a second request for 
the available bills for the second user, and to 
direct the transmission of the stored first bill 
identifier responsive to the received first 30 
request and the stored second bill identifier 
responsive to the received second request. 

21. A system according to claim 18, wherein: 

35 

the associated information available at the first 
network address includes promotional informa- 
tion; and 

the information available at the second network 
address excludes the promotional information. 40 

22. A database for storing bill related information, com- 
prising: 

identifiers of a plurality of different users; 45 
identifiers of a plurality of available bills of a 
biller for the plurality of different users; and 
a network location indicator associated with 
one or more of the plurality of available bills and 
indicating that a network location at which infor- so 
mation associated with the one or more bills is 
available is different than a network location at 
which information associated with other of the 
plurality of available bills is available. 

55 

23. An article of manufacture for electronically transmit- 
ting bill related information, comprising: 



a computer readable storage medium; and 
computer programming stored on the medium 
and configured to be readable from the 
medium by a computer processor and thereby 
cause the processor to operate so as to: 
direct transmissions of a plurality of identifiers 
of available bills of a plurality of different billers 
for a plurality of different users, including a first 
of the plurality of bill identifiers which identifies 
a first of the available bills of a first of the plural- 
ity of different billers for a first of the plurality of 
different users and a second of the plurality of . 
bill identifiers which identifies a second of the" 
available bills of the first biller for a second of 
the plurality of users; and 
direct transmissions of a plurality of different 
network addresses at which information asso- 
ciated with the identified available bills is avail- 
able, including a first of the plurality of network 
addresses at which information associated with 
the identified first available bill, is available to 
the first user, and a second of the plurality of 
network addresses, different than the first net- 
work address, at which information associated 
with the second available bill is available to the 
second user. 

24. An article of manufacture according to claim 23, 
wherein: 

the information associated with the identified 
first available bill includes promotional informa- 
tion; and 

the information associated with the identified 
second available bill excludes the promotional 
information. 

25. An article of manufacture according to claim 23, 
wherein the stored computer programming is read- 
able by the computer processor to thereby cause 
the processor to further operate so as to: 

direct the transmission of the first network 
address as a first hyperlink in association with 
the transmission of the first bill identifier; and 
direct the transmission of the second network 
address as a second hyperlink in association 
with the transmission of the second bill identi- 
fier. 

26. An article of manufacture according to claim 23, 
wherein the stored computer programming is read- 
able by the computer processor to thereby cause 
the processor to further operate so as to: 

receive requests for the available bills for the 
plurality of users including a first request for the 
available bills for the first user and a second 
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request for the available bills for the second 
user; and 

direct the transmission of the first bill identifier 
responsive to the received first request and the 
second bill identifier responsive to the received s 
second request. 

27. An article of manufacture according to claim 23, 
wherein the identified first available bill is available 
at the first network address and the second availa- w 
ble bill is available at the second network address. 
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